FIG. 14 is a view showing a configuration of a radio access network (hereinafter, referred to as IP-RAN) 102 on the basis of IP technology of a mobile communication system with the use of the IMT 2000 system.
In FIG. 14, the IP-RAN 102 includes: a radio network controller (hereinafter, referred to as IP-RNC) 103 connected to a core network 101; a router 104; and base transceiver stations (hereinafter, referred to as IP-BTS) 105 and 106 connected to the router 104. The IP-RAN 102 is a network that provides a terminal 107 with mobile communication.
A Connection Frame Number (hereinafter, referred to as CFN), which is a frame sequence number that increases its value as the time advances as specified in 3GPP TS 25.427, is applied to a data frame transmitted and received between the IP-RNC 103 and the IP-BTS 105. Synchronisation control specified in 3GPP TS 25.402 is performed for the data frame. The synchronisation control is performed as follows. When a reception timing of a frame is out of a Receiving Window that is a temporal receiving range, the period out of the window is informed to the transmitting side by use of a Timing Adjustment control frame. The synchronisation control is performed by receiving the frame and then adjusting the transmission timing of the frame so that the reception timing of the frame falls within the Receiving Window (which means that the transmission schedule is changed).
This data frame is, as shown in FIG. 15, has a header part of 2 bytes and a payload part of a variable length. The header part is composed of Frame CRC, FT (Frame Type), and Control Frame Type.
The payload part of a variable length, when it is used for a Timing Adjustment control frame, is composed of a CFN of 1 octet, a TOA (Time Of Arrival) of 2 octets, and Spare Extension part of 0 to 32 octets.
Referring back to FIG. 14, if the round-trip transmission delay between the IP-RNC 103 and the IP-BTS 105 is constant, the reception timing of the frame should fall within a Receiving Window by adjusting the transmission timing. However, since the round-trip transmission delay between the IP-RNC 103 and the IP-BTS 105 varies according to the congestion level of the IP-RAN from moment to moment, it is necessary to change the transmission schedule. In the following, a description will be given of changing of the transmission schedule of Iub data frames in a case where the round-trip transmission delay varies.
For example, regarding a connection call 108 from the terminal 107, after Transport Channel Synchronisation is completed at a synchronisation control 109 between the IP-RNC 103 and the IP-BTS 105, the round-trip transmission delay between the IP-RNC and IP-BTS is assumed to vary as listed below.    Time A (0.00 to 1.00 seconds): 10 msec (one way: 5 msec)    Time B (1.00 to 1.05 seconds): 30 msec (one way: 15 msec)    Time C (1.05 to 2.00 seconds): 50 msec (one way: 25 msec)    Time D (2.00 seconds and later): 200 msec (one way: 100 msec)
FIG. 17 is a view showing transmission and reception of Iub data frames from the IP-RNC 103 to the IP-BTS 105 from Time A, through Time B, to Time C. In the drawing, downlink Iub data frames 202 are sequentially transmitted from the IP-RNC 103 in accordance with the frame transmission schedule. The frame transmission schedule is assumed to be sequentially shifted in the order of a schedule 201, a schedule 206, and a schedule 210.
In addition, a Receiving Window 203 is set at the IP-BTS 105. Sequential numbers are applied to the Receiving Windows, respectively. In the present example, the Receiving Windows applied with even numbers are employed.
Herein, it is assumed that a fixed value of “160 msec” is set to be a period 207. The period starts immediately after the transmission timing is adjusted, as a period in which the received Timing Adjustment control frame is ignored. Hereinafter, each of the operations in Time A, time B, and Time C will be described.
(Operation in Time A)
After the Transport Channel Synchronisation is completed, the IP-RNC 103 transmits Iub data frames applied with CFNs, in accordance with the frame transmission schedule 201.
For instance, the downlink Iub data frame 202 (applied with the CFN “120”) that is transmitted on the frame transmission schedule 201 is received in the Receiving Window 203 of the corresponding CFN of the IP-BTS 105.
(Operation in Time B)
Then, in Time B, the round-trip transmission delay between the IP-RNC 103 and the IP-BTS 105 varies, and then the synchronisation established by the Transport Channel Synchronization is lost. Specifically, a downlink Iub data frame 204 transmitted in accordance with the frame transmission schedule 201 arrives at the IP-BTS 105 with “10 msec” delayed than before. The IP-BTS 105 informs the IP-RNC 103 of the delay of “10 msec” (that is, TOA=−10) by use of a Timing Adjustment control frame (hereinafter, referred to as TA) 205. Specifically, a TOA of a positive value is informed in a case where the IP-BTS 105 receives earlier than a reception timing expected by the IP-BTS 105, whereas a TOA of a negative value is informed in a case where the IP-BTS 105 receives later than that.
Incidentally, TA is specified in Chapter 7.2 in 3GPP TS 25.402. In other words, as shown in FIG. 18, a DL DATA frame transmitted from the IP-RNC to the IP-BTS is received at a timing out of the Receiving Window. Then, the IP-BTS transmits, to the IP-RNC, a TA including a TOA indicative of a period being out of the Receiving Window.
Referring back to FIG. 17, the IP-RNC 103 moves the transmission schedule forward by 10 msec as indicated by the TA 205, and changes the frame transmission schedule to the transmission schedule 206. At this point of time (that is, when the TA 205 is received), the first period 207 starts. While the first period 207 is continuing (that is, for 160 msec), the frame transmission schedule is not changed even if other TAs are received. In other words, any received TA is ignored, while the first period 207 is continuing.
(Operation in Time C)
In Time C, the round-trip transmission delay varies again, so the IP-BTS 105 informs that no downlink Iub data frame has been received in a Receiving Window, by use of four TAs 208. However, the afore-mentioned four TAs 208 arrive at the IP-RNC 103 in the first period 207. Accordingly, these TAs are ignored and the frame transmission schedule of the IP-RNC 103 will not be changed.
Subsequently, the first period 207 elapses, and the reception of a TA 209 permits the IP-RNC 103 to change the frame transmission schedule to the frame transmission schedule 210.
In this situation, the conventional system has a drawback in that the first period 207 hinders reacting to the four TAs 208 and delays the recovery of synchronisation.
(Operation in Time D)
Meanwhile, FIG. 19 and FIG. 20 are views showing transmission and reception of the Iub data frames between the IP-RNC 103 and the IP-BTS 105 in Time C to Time D.
In Time C, a downlink Iub data frame transmission schedule 301 establishes the synchronisation between the IP-RNC and the IP-BTS.
Turning to Time D, as the downlink one-way transmission delay increases from “25 msec” to “100 msec”, a downlink Iub data frame 302 applied with CFN of 36 arrives at the IP-BTS 105 “75 msec” later than a Receiving Window 303 for the frame applied with CFN of 36. Upon reception of this, the IP-BTS 105 informs the IP-RNC 103 of this “75 msec” delay, as TOA=−75, by use of a TA 304.
The IP-RNC 103 receives the TA 304 and changes the frame transmission schedule 301 to a frame transmission schedule 305, and simultaneously starts a first period 306. Since then, the transmission delay between the IP-RNC and the IP-BTS does not change, so the frame transmission schedule 305 does not have to be changed any more.
In fact, the IP-RNC 103, however, after the first period 306 elapses, changes the frame transmission schedule to a frame transmission schedule 308 upon reception of a TA 307. This is an unnecessary change of the frame transmission schedule.
A drawback in the conventional system is that such an insufficient time length of the first period 306 changes the frame transmission schedule in response to the TA 307 that should be ignored, thereby making it impossible to perform the synchronisation control between the IP-PNC and the IP-BTS correctly.
Incidentally, JP 2005-269061 A (hereinafter, referred to as Document 1) discloses that the information about a synchronisation timing error is communicated from the receiving side to the transmitting side, so as to adjust the transmission timing based upon the information.